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Description 

5 METHODS AND SYSTEMS FOR COMMUNICATING SS7 MESSAGES 
OVER PACKET-BASED NETWORK USING TRANSPORT ADAPTER 

LAYER INTERFACE 

Related ApDlications 

10 This application is a continuation-in-part of U.S. Patent Application 

Serial No. 09/443,712 filed November 19. 1999, and further claims the 
benefit of U.S. Provisional Application Serial No. 60/137,988 filed June 7, 
1999, the disclosures of both of which are incorporated herein by reference 
in their entirety. 

15 

Technical Held 

The present invention relates to methods and systems for 
communicating SS7 messages over a packet-based network. More 
particulariy, the present invention relates to methods and systems for 
20 communicating SS7 messages over a packet-based network using a 
transport adapter layer interface. 
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Backoround Art 

The traditional public switched telephone network (PSTN) consists of 
signaling nodes connected via dedicated signaling system 7 (SS7) signaling 
links. The three primary types of signaling nodes In the conventional PSTN 
5 network are service switching points (SSPs), signal transfer points (STPs). 
and service control points (SCPs). Sen^ice switching points are end office 
switches that handle both voice and data traffic. Signal transfer points are 
switching nodes that route SS7 messages between SS7 signaling points. 
Service control points are databases and associated computers that provide 
10 data in response to SS7 queries. Examples of such data include billing 
information, 800 number translation infomriation, and number portability 
information. 

These conventional SS7 nodes have typically communicated by 

sending SS7 messages to each other over dedicated SS7 signaling links. 
15 While such signaling links provide a highly reliable means for communicating 

SS7 traffic, SS7 signaling links provide only fixed bandwidth to a user 

regardless of the user's needs. As a result, users must install or lease 

sufficient call signaling bandwidth to handle peak or worst-case trafflc 

conditions. Installing or leasing sufficient call signaling bandwidth for peak 
20 conditions is inefficient, since peak conditions rarely occur. Moreover, 

because SS7 call signaling bandwidth is expensive, there exists a need for 

an alternative to dedicated SS7 signaling links. 

I 

Figure 1 is a block diagram of the conventional PSTN network. In 
Figure 1, SSPs 100 and 102 communicate with SSPs 104 and 106 through 

i 
I 
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STPs 108. 110, 112, and 114. SCP database nodes 116 and 120 provide 
data in response to queries from SSPs 100, 102, 104 and 106 and/or from 
STPs 108, 110, 112, and 114. Alt of the lines interconnecting the nodes in 
Figure 1 represent conventional SS7 signaling links. As stated above, such 
5 links are often under-utilized and are expensive to install or lease. 

In packet-based networks, such as transmission control 
protocol/Internet protocol (TCP/IP) networks, bandwidth can be shared 
among multiple users. In addition, the growth and popularity of the global 
Internet have made components for such networks readily available and cost 

10 efficient. However, integrating the traditional PSTN network with a packet- 
based network, such as a TCP/IP network, creates a number of problems. 

For example, one problem with sending traditional call signaling traffic 
over a TCP/IP network is that in a TCP/IP network, transmissions between a 
sender and a receiver are stream-oriented. That is, TCP software on a 

15 sending machine is not guaranteed to send data in the same boundaries 
defined by a sending application. The amount of data sent over a TCP 
connection depends on the window size advertised by the receiver, the 
number of bytes of data that have been acknowledged by the receiver, and 
the maximum segment size of the physical network connecting the sender 

20 and the receiver. Accordingly, the receiving application may not receive data 
in the same boundaries created by the sending application. Thus, when 
sending call signaling messages over a TCP/IP network, several messages 
may be combined in one TCP segment. Alternatively, a single call signaling 
message may be divided among multiple TCP segments. In conventional 
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networks, it is the job of the receiving application to parse the incoming data 
stream and extract the individual packets. Such parsing is difficult and 
increases the complexity of application programs that utilize TCP. 

Another problem with sending conventional call signaling messages 
5 over a TCP/IP connection is that the timeout period for disabling a 
connection in TCP is too long for call signaling applications. For example, 
. some implementations of TCP include a keep-alive timer. The keep-alive 
timer is reset every time a TCP segment is received. When the timer 
expires, it causes one side of the connection to determine if the other side is 

10 still operating. No mechanism is specified in the TCP protocol specifications 
for determining whether the other side is operating. In addition, the timeout 
period for the keep-alive timer is on the order of minutes. Thus, one side of 
a connection could go down and the other side could wait for minutes before 
resetting the connection. Such a long timeout period wastes resources on 

IS the machine that is waiting for data from the other side and is unsuitable for 
telephony applications. 

Yet another problem with integrating conventional telephony and 
packet-based networks, such as TCP/IP networks, is that TCP/IP requires 
lengthy handshake procedures for connection establishment and 

20 termination. For example, in order to establish a TCP connection, a client 
application sends a synchronization (SYN) packet to a server application. 
The server application then sends an acknowledgement (ACK) and a SYN 
back to the client. The client then sends an acknowledgement to the SYN + . 
ACK from the server. During the initial exchange of SYN and ACK 
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messages, the client and server exchange sequence numbers. Once the 
client sends acknowledgement to the SYN + ACK to the server, the TCP 
software on the client machine is in an open state in which data can be 
received from the server and data from the sending application can be sent 
5 to the server. 

In order to terminate a TCP connection, when an application closes a 
connection, the TCP software associated with that application sends a FIN 
packet to the TCP software on the other side of the connection. The TCP 
software of the machine that receives the FIN sends an ACK to the FIN and 

10 infomis the application that a FIN has been received. If the application is 
finished sending data, the application closes the connection. In response to 
the application close, the TCP software sends a FIN to the TCP software 
that sent the original FIN. In response to receiving the FIN, the TCP 
software sends an ACK. Once this ACK is sent, the connection is 

1 5 considered to be closed by both sides of the connection. 

While TCP connection establishment and termination procedures 
have proven to be reliable and account for a variety of error conditions, such 
procedures are cumbersome and require many round trip times in order to 
complete. For example, in TCP connection establishment, a minimum of 1.5 

20 round trip times is required. In the TCP connection termination scenario 
described above, at least two round trip times are required. In addition, TCP 
software on both sides of the connection is required to maintain state and 
perform additional processing during connection establishment and 
termination. 
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For all of these reasons, the number of occurrences of TCP 
connection establishment and termination procedures should be minimized. 
For example, if it is desired to upgrade software in a telephony device that 
cun-ently communicates with a remote device over a TCP connection, the 
5 connection must be terminated. Connection termination requires the 
handshaking procedure discussed above. Once the software is upgraded, 
the connection must be reestablished. Connection reestablishment requires 
the three-way handshaking procedure described above. Thus, performing a 
software upgrade requires an initial TCP connection establishment, a TCP 
10 connection termination, followed by another TCP connection establishment. 
These procedures waste resources and should be minimized, especially in 
high-traffic telecommunications switches. 

In light of all these difficulties associated with integrating conventional 
telephony networks, such as SS7 networks, and stream-oriented packet- 
IS based networks, such as TCP networks, there exists a need for novel 
methods and systems for integrating these networks that avoid at least some 
of the difficulties associated with the prior art. 

Disclosure of the Invention 
20 The present invention includes methods and systems for 

communicating SS7 messages between signaling nodes over a packet- 
based network using a transport adapter layer interface. As used herein, the 
phrase transport adapter layer interface refers to an interface that resides 
above the transport layer in the TCP protocol stack that facilitates integration 
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between the SS7 protocol stack and the TCP/IP protocol stack. Such an 
interface includes functionality for prohibiting and allowing communications 
over a socket without Invoking conventional TCP connection establishment 
and termination handshaking procedures. In addition, the interface provides 
5 monitor and test messages that are respectively used to measure 
performance and test the status of a connection. The interface also provides 
a mechanism for encapsulating SS7 messages that allows individual 
message identification over a stream-oriented connection. 

Embodiments of the invention will be described below as modules. 

10 layers, or processes for implementing SS7 and IP communications functions, 
it is understood that these modules, layers, or processes can be 
implemented as hardware, software, or a combination of hardware and 
software. For example, transport adapter layer interface functionality is 
described below as a process implemented on a data communications 

15 module. The data communications module may include hardware, such as a 
microprocessor and associated memory, for executing and storing programs. 
The TALI process may be executed by the microprocessor to perform the 
TALI functions described below. 

Accordingly, it is an object of the invention to provide novel methods 

20 and systems for communicating SS7 messages over a stream-oriented 
packet-based network that avoids the problems with conventional stream- 
oriented packet-based networks. 
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It is another object of the invention to provide methods and systems 
for allowing and prohibiting service data communications over a stream- 
oriented connection without invoking a TCP handshaking procedure. 

It is yet another object of the invention to provide methods and 
5 systems for identifying message packets received over a stream-oriented 
connection. 

Some of the objects of the invention having been stated hereinabove, 
other objects will be evident as the description proceeds, when taken in 
connection with the accompanying drawings as best described hereinbelow. 
10 Brief Description of the Drawings 

Preferred embodiments of the invention will now be described with 
reference to the accompanying drawings of which: 

Figure 1 is a block diagram illustrating the conventional PSTN 
network; 

15 Figure 2 is a block diagram of an exemplary operating environment 

for embodiments of the present invention; 

Figure 3 is a block diagram of a signaling gateway capable of sending 
SS7 messages over a packet-based networi< using a transport adapter layer 
internee according to an embodiment of the present invention: 

20 Figures 4(a) and 4(b) are block diagrams illustrating the relationships 

between the SS7 and IP protocol stacks and methods for integrating the 
protocol stacks using a transport adapter layer interface according to 
embodiments of the present invention; 
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Figure 5 is a block diagram illustrating an exemplary packet structure 
for encapsulating of SCCP messages using a transport adapter layer 
interface according to an embodiment of the present invention; 

Figure 6 is a flowchart illustrating exemplary steps that may be 
5 performed by a signaling gateway in encapsulating SCCP messages using a 
transport adapter layer interface according to an embodiment of the present 
invention; 

Figure 7 is a block diagram illustrating an exemplary packet structure 
for encapsulating MTP3 messages using a transport adapter layer interface 
1 0 according to an embodiment of the present invention; 

Figure 8 is a block diagram illustrating an exemplary packet structure 
for encapsulating SS7 messages using an ATM adaption layer and a 
transport adapter layer interface according to an embodiment of the present 
invention; 

IS Figure 9 is a flowchart illustnating exemplary steps for identifying 

individual message packets received over a stream-oriented connection 
according to an embodiment of the present invention; 

Figure 10 is a flowchart illustrating exemplary steps for monitoring 
connection status using transport adapter layer interface messages 
20 according to an embodiment of the present invention; 

Figure 1 1 is a flowchart illustrating exemplary steps for allowing and 
prohibiting communications using a transport adapter layer interface 
according to embodiments of the present invention; and 
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Figure 12 is a flowchart illustrating exemplary steps for measuring 
round trip time using transport adapter layer interface messages according 
to an embodiment of the present invention. 

5 Detailed Description of the Invention 

Figure 2 illustrates an exemplary operating environment for 
embodiments of the present invention. In Figure 2, conventional SS7 
network elements, such as SSPs 200. 202, and 204 and SCP 206, 
communicate with each other over SS7 network 208. IP nodes, such as 

10 media gateways (MGs) 210, 212, and 214, media gateway controllers 
(MGCs) 216 and 218 and Internet service provider (ISP) 220, communicate 
with each other over first packet-based network 222. Similarly, signaling 
gateways 224 and 226 communicate with MGCs 216 and 218 and with SCP 
228 via second packet-based network 230. First and second packet-based 

IS networks 222 and 230 may each comprise IP networks. Moreover, first and 
second packet-based networks 222 and 230 may be the same logical 
network. The reason that networks 222 and 230 are illustrated separately in 
Figure 2 is that first packet-based network 222 carries packetized media 
stream communications between MGs, and media control information 

20 between MGCs and MGs, and second packet-based network 230 carries call 
signaling traffic to and from SGs 224 and 226. 

The conventional SS7 network elements, such as SSPs and SCPs. 
are described in detail above. Hence a description thereof will not be 
repeated herein. The additional network elements illustrated in Figure 2 
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include media gateways 210, 212, and 214, media gateway controllers 216 
and 218, signaling gateways 224, and 226. and Internet service provider 
(ISP) 220. Media gateways 210, 212, and 214 encapsulate media stream 
communications, such as audio, video, and data, in IP packets to be 

5 transmitted over first packet-based network 222. An example of a protocol 
used to send media stream communications over a packet-based network is 
the real time protocol (RTP) as defined in RFC 1889. RTP: A Transport 
Protocol for Real Time ApDilcations . Jacobson et al.. January 1 996. 

MGCs 216 and 218 control MGs 210, 212, and 214 using a control 

10 protocol. An example of a control protocol that may be implemented by 
MGCs 216 and 218 is the media gateway control protocol as described in 
Media Gateway Control Protocol (MGCPl . http://search.ietf.org/intemet- 
drafts/draft-huitema-mejaco-mgcp-vOr1-05.b(t, February 21, 1999. ISP 220 
provides Internet services to subscribers. Accordingly, ISP 220 may include 

1 5 a network access server to provide user access to the Internet. 

Signaling gateways 224 and 226 implement an interface between 
SS7 network 208 and second packet-based network 230. In a preferred 
embodiment of the invention, signaling gateways 224 and 226 provide a 
transport adapter layer interface to allow conventional network elements, 

20 such as SSPs 200. 202. and 204, to communicate with IP network elements, 
such as MGCs 216 and 218. However, the transport adapter layer interface 
is not limited to communications between SSPs and MGCs. For example, 
the transport adapter layer interface according to embodiments of the 
present invention may also be used to communicate call signaling messages 
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to IP-based SCPs, such as SCR 228 and other devices equipped with an IP 
interface. 

Figure 3 is a block diagram illustrating a signaling gateway for 
implementing transport adapter layer interface functionality according to an 

5 embodiment of the present invention. In Figure 3, signaling gateway 224 
includes SS7 link interface module (LIM) 300 for sending and receiving SS7 
messages over an SS7 network and data communications module (DCM) 
302 for sending and receiving SS7 messages over one or more stream- 
oriented connections. Signaling gateway 224 may also include additional 

10 modules, such as database service module (DSM) 304, for providing SCCP 
and database services. Modules 300, 302 and 304 are connected by an 
interprocessor message transport (IMT) bus 306. IMT bus 306 is preferably 
a dual ring counter rotating bus for increased reliability. 

Link interface module 300 includes a number of processes for 

15 sending and receiving SS7 messages over SS7 links. In the illustrated 
embodiment, link interface module 300 includes MTP level 1 and 2 process 
307 for performing SS7 layer 1 and 2 processing of incoming messages. I/O 
queue 308 enqueues incoming and outgoing SS7 messages. Message 
discrimination process 309 determines whether incoming messages are 

20 addressed to signaling gateway 224 or to another node. For example, 
message discrimination process 309 may analyze the SS7 destination point 
code in an incoming message to detennnine whether the message is 
addressed to signaling gateway 224 or to another node. If message 
discrimination process 309 determines that the message is addressed to 
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signaling gateway 224. message discrimination process 309 fonvards the 
message to message distribution process 310. Message distribution 
process 310 routes the message to another internal module for further 
processing. 

5 DSM 304 provides database and SCCP service for SS7 rtiessages. 

Accordingly, DSM 304 may include signaling connection routing control 
(SCRC) and SCCP processes 312 and 314 for interpreting SCCP layer 
information of incoming messages and routing the messages to database 
process 316. Database process 316 may perform a lookup in database 318 

10 to obtain routing or other information for an incoming message. For 
example, database 318 may be a number portability database, a circuit 
identification code routing database, a billing code database, or other 
database for performing routing or other functionality. Routing process 320 
routes the message to the appropriate module for outgoing processing 

15 based on MTP layer 3 information in the message. 

DCM 302 includes transport adapter layer interface process 322 for 
performing transport adapter layer interface functionality. Such functionality 
includes encapsulating SS7 messages in a transport adapter layer interface 
packet to be sent over a stream-oriented connection, allowing and 

20 prohibiting communication over a stream-oriented connection, monitoring the 
other end of the stream-oriented connection, etc. DCM 302 preferably also 
includes a stream-oriented communication process such as TCP/IP process 
324. TCP/IP process 324 performs conventional TCP/IP protocol stack 



SUBSTITUTE SHEET (RULE 26) 



wo 00/76134 



PCTAJS00/1S561 



-14- 

functions. Such functions include reliable delivery of TCP/IP packets, flow 
control, packet sequencing, and other stream-oriented transport functionality. 

Figure 4(a) is a block diagram illustrating the relationships between 
the SS7 protocol stack and the transport adapter layer interface protocol 
S stack according to an embodiment of the present invention. In Figure 4, SS7 
protocol stack 400 includes MTP layer 1 402, MTP layer 2 404, and MTP 
layer 3 406. MTP layer 1 402, also referred to as the physical layer, 
communicates with hardware to send and receive data over a physical 
medium. MTP layer 2 404, referred to as the data link layer, provides error 
10 correction/detection and properly sequenced delivery of SS7 message 
packets. MTP layer 3 406, also refen-ed to as the network layer, is 
responsible for SS7 message routing, message discrimination, and message 
distribution. 

Residing above MTPs layers 1 - 3 is the user parts and application 
IS parts layer 408. User parts and application parts layer 408 is divided into 
ISDN user part (ISUP) layer 410. signaling connection control part (SCCP) 
layer 412 and transaction capabilities application part (TCAP) layer 414. 
ISDN, user part layer 410 performs SS7 call setup and call teardown 
functions. SCCP layer 412 performs signaling connection control part 
20 functions, such as database subsystem addressing. TCAP layer 414 is used 
for database transactions, such as 800 number translations, number 
portability transactions, and billing transactions. Finally, SS7 application 
layer 416 can perform any function that uses the underlying services 
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provided by SS7. Examples of such applications include billing applications, 
network monitoring applications, etc. 

TALI protocol stack 418 includes IP protocol stack portion 420. TALI 
portion 422, and SS7 portion 424. IP protocol stack portion 420 includes a 
S physical and MAC layer 426, a network layer 428, and a transport layer 430. 
Physical and MAC layer 426 internees with network hardware for 
communication between connected machines and transports network frames 
between machines connected to the same network. Network layer 428 
handles routing and addressing of datagrams between different physical 

10 networks. In a prefen-ed embodiment of the invention, network layer 428 
performs addressing and routing functions according to the Internet protocol, 
such as Internet protocol version 4 or Internet protocol version 6. Transport 
layer 430 provides communication between application programs. In a 
preferred embodiment of the present invention, transport layer 430 includes 

15 stream-oriented transport software, such as TCP software, for implementing 
reliable stream-oriented transport between applications. 

It should be noted that although TALI protocol stack 418 illustrated in 
Figure 4(a) includes MTP3 layer 406. MTP layer 3 functionality, other than 
processing point codes, is optional and may be omitted from TALI protocol 

20 stack 418. 

According to an important aspect of the present invention, transport 
adapter layer interface portion 422 includes functions and packet structures 
that facilitate interoperability between the SS7 and TCP protocols. For 
example, transport adapter layer interface portion 422 includes packet 
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Structures that facilitate extraction of SS7 packets from a TCP data stream, 
commands for allowing and prohibiting connections without invoking TCP 
connection establishment and termination procedures, monitor messages for 
measuring round trip time, and test messages for determining whether a 
5 TCP connection is enabled or disabled. Each of these functions will be 
discussed in more detail below. 

Traditional SS7 devices 436, such as SSPs, STPs, and SCPs, 
communicate with signaling gateway 224 using SS7 protocol stack 400. 
TCP/IP devices 438, such as MGCs and IP-based SCPs, communicate with 
10 signaling gateway 224 using TALI protocol stack 418. Accordingly, signaling 
gateway 224 preferably includes software for implementing both SS7 
protocol stack 400 and TALI protocol stack 418. 

As illustrated in Rgure 3, SS7 protocol stack 400 may be 
implemented by or on LIM 300 and TALI protocol stack 418 may be 
15 implemented by or on DOM 302. However, the present invention is not 
limited to such an implementation. For example, in an alternative 
embodiment of the invention, SS7 protocol stack 400 and TALI protocol 
stack 418 may be implemented on a single card or module within signaling 
gateway 224 or in another node in which SS7 and IP communication 
20 capability is. desirable. 

Figure 4(b) is a block diagram illustrating an altemative 
implementation of the TALI protocol stack according to an embodiment of 
the present invention. In Figure 4(b), SS7 protocol stack 400a includes 
MTP3, SCCP. TCAP, ISUP, and application layers 406. 412. 414, and 416 
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that are identical to the correspondingly numbered layers described with 
respect to Figure 4(a). However, in Figure 4(b) MTP layers I and 2 are . 
replaced by asynchronous transport mode (ATM) layer 450, ATM adaption 
layer 5 452, and signaling ATM adaption layer 454. Layers 450, 452, and 
5 454 perform functions for transmitting SS7 traffic over a broadband network, 
such as an ATM network. 

TALI protocol stack 418a includes MAC, network, transport, TALL and 
SS7 layers 426. 428, 430. 422, and 424. that are identical to the 
correspondingly numbered layers described with respect to Figure 4(a). 

10 However, TALI protocol stack 418a includes signaling ATM adaption layer 
(SAAL) 454 to provide sequencing of SS7 data transferred across a TCP/IP 
connection. When TALI protocol stack 418a is implemented without SAAL 
layer 454, as illustrated in Rgure 4(a), the SS7 sequence number, which is 
included in the SS7 MTP2 header, is not transferred across a TCP/IP 

15 connection. This sequence number is used to preserve message 
sequencing and to support complex SS7 procedures involving MSU retrieval 
during link changeover and changeback. Changeover is an SS7 procedure 
whereby a link request is sent over one SS7 link to move SS7 traffic from 
that link to another SS7 link. Changeback is an SS7 procedure for moving 

20 the SS7 traffic back to the original link. TALI protocol stack 418 illustrated in 
Figure 4(a) without SAAL layer 454 still guarantees correct sequencing of 
SS7 data because TCP layer 430 provides sequencing of TCP segments 
that carry the SS7 traffic. 

•» 
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When TALI protocol stack 418a is implemented with SAAL layer 454. 
the sequence number of the SS7 MSU is part of the data transferred across 
a TCP/IP connection. This sequence number may be included as a header, 
a trailer, or in any other portion of a transport adapter layer interface packet. 

S In the illustrated example, the sequence number is a 24-bit value included in 
a service specific connection oriented protocol (SSCOP) trailer provided by 
SAAL layer 454. This 24-bit sequence number serves the same purpose as 
the 8-bjt SS7 sequence number. Accordingly, TALI protocol stack 418a 
illustrated in Figure 4(b) can be used for SS7 changeover and changeback 

10 with data retrieval and can minimize MSU loss when SS7 links are 
deactivated. 



SCCP Encapsulation Using TALI 
Figure 5 illustrates a packet stmcture for encapsulating SCCP MSUs 

15 in IP packets using the transport adapter layer interface according to an 
embodiment of the present invention. In Figure 5, SS7 IVISU 500 includes 
SCCP layer information 502 and TCAP layer information 504 that are 
encapsulated in service portion 506 of TALI packet 508. SS7 MSU 500 also 
includes service indicator octet 510 and routing label 512. In one 

20 embodiment of the invention, sen/ice indicator octet 510 and routing label 
512 may be encapsulated directly in service portion 506 of TALI packet 508. 
However, in the illustrated embodiment, service indicator octet 510 and 
routing label 512 are omitted from TALI packet 508. Omitting the service 
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indicator octet and routing label information from the TALI packet simplifies 
processing by the receiving TALI process. 

Rather than encapsulating service indicator octet 510 and routing 
label 512 directly in service field 506 of TALI packet 508, TALI protocol 
S software according to embodiments of the present invention may store 
information from SIO 510 and routing label 512 in other information fields. 
For example, the destination point code from routing label 512 may be 
stored in the SCCP called party point code field of SCCP layer 502. 
Similarly, the originating point code from routing label 512 may be stored in 

10 the SCCP calling party point code field of routing label 512. Message type 
identification information from SIO 510 may be merged to OPCODE field 514 
of TALI packet 508. For example. OPCODE field 514 may store information 
for identifying the message type. In the illustrated embodiment, OPCODE 
field 514 may be set to a predetermined value for identifying the message as 

15 an SCCP message. The remaining fields of SS7 MSU 500 are preferably 
omitted from TALI packet 508. That is, SS7 layer 2 information, opening 
flags, closing flags, and frame check sequences are preferably omitted from 
TALI packet 508. This infomnation can be omitted because the TCP/IP 
protocol stack provides analogous functions to SS7 layers 1 and 2. Omitting 

20 SS7 layers 1 and 2 from TALI packet 508 decreases overhead for sending 
packets over a network. 

In addition to service field 506 and OPCODE field 514, TALI packet 
508 also includes LENGTH field 516 and SYNC field 518. LENGTH field 
516 specifies the length of the service portion of the data packet. SYNC field 
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518 contains a predetermined bit sequence for identifying the start of TALI 
packet 508. LENGTH field 516 and SYNC field 518 may be used by 
receiving TALI protocol software to extract individual TALI packets from a 
stream-oriented connection. Thus, the TALI packet structure in Figure 5 
5 solves the problem of receiving data over a stream-oriented communication 
and delivers individual TALI packets to an application. This simplifies 
application design, as will be discussed in more detail below. 

TALI packet 508 is encapsulated in data portion 520 of network frame 
522. Network frame 522 may be any suitable frame for delivering packets to 

10 machines connected to the same network. For example, network frame 522 
may be an Ethernet frame. Accordingly, network frame 522 includes a 
mediated access control (MAC) header 524. IP header 526 follows MAC 
header 524. Finally, TCP header 528 follows IP header 526. The structure 
of headers 524, 526. and 528 is known to those of ordinary skill in the art 

1 5 and need not be described herein. 

Figure 6 is a flowchart illustrating exemplary steps that may be 
performed by TALI process 322 illustrated in Figure 3 for performing TALI 
encapsulation of an SCCP MSU. In Figure 6. in step ST1, TALI process 322 
receives an SS7 MSU. The SS7 MSU may originate from an SS7 node, 

20 such as an SSP. In step ST2. TALI process 322 discards MTP layer 2 
infonn'ation, SRC, and flags from the SCCP MSU. In step ST3. TALI 
process 322 places the destination point code from the routing layer into the 
called party address field of the SCCP layer. In step ST4, TALI process 322 
places the originating point code from the routing label in the calling party 
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address field of the SCCP layer. It is understood that steps ST3 and ST4 
are optional and can be omitted if the entire MTP3 portion of the SCCP MSU 
is encapsulated in the service portion of the TALI packet. 

In step ST5, TALI process 322 sets the SYNC field in the header of 
S the TALI packet to indicate the beginning of the TALI packet. In ST6. TALI 
process 322 sets the OPCODE field of the TALI packet to SCCP. In step 
ST7. TALI process 322 sets the LENGTH field is set to the number of octets 
in the service field of the TALI packet. Finally, in step ST8, TALI process 
322 sends the packet to TCP/IP process 324 for TCP/IP encapsulation and 

10 transmission to an external node. 

The steps for processing an incoming TALI packet are essentially the 
reverse of the steps illustrated in Figure 6. Novel steps for processing 
incoming TALI packets will be discussed in more detail below in the section 
entitled "Identifying Individual Message Packets Received Over Stream- 

15 Oriented Connection." 
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MTP3 Encapsulation Using TALI 
Figure 7 is a block diagram illustrating an exemplary packet structure 
for encapsulating MTP3 messages in IP packets according to a preferred 
embodiment of the present invention. As used herein, an MTP3 message is 
5 an SS7 message that is not an SCCP or an ISUP message. These 
messages correspond to service indicator values of 0 - 2, 4. and 6-15. In 
Figure 7. SS7 MSU 700 includes layer 2 702, layer 3 703. and opening and 
closing information 704 and 706. Unlike the example illustrated in Figure 5. 
in this example, all of layer 3 Infonmation is encapsulated in service portion 

10 506 of TALI packet 508. Like the example illustrated in Figure 5, layer 2 
information 702, and opening arid closing information 704 and 706 are 
preferably discarded. 

In TALI packet 508, LENGTH field 516 is set to the length of service 
portion 506. OPCODE field 514 is set to a predetermined value for 

15 identifying an MTP3 packet. SYNC field 518 is set to a predetermined value 
for identifying the start of TALI packet 508. TALI packet 508 is encapsulated 
in network frame 522 in the same manner described above v/ith respect to 
Figure 5. Thus, the present invention provides a method for encapsulating 
MTP3 messages other than ISUP and SCCP messages In network frames 

20 using a transport adapter layer Interface. 

SAAL Encapsulation Using TALI 
As illustrated above with regard to Figure 4(b). one embodiment of the 
transport adapter layer interface protocol stack includes a SAAL layer. TALI 
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also provides a corresponding SAAL OPCODE that indicates that a SAAL 
message is being transported. This OPCODE may be used to transport any 
type of SS7 message. Including ISUP messages, SCCP messages, and 
MTP3 messages that includes SAAL information. In addition, the SAAL 
5 OPCODE may be used to transport non-SS7 messages, such as SAAL 
peer-to-peer messages. 

Figure 8 illustrates encapsulation of SAAL messages using a 
transport adapter layer interface according to an embodiment of the present 
invention. In Figure 8, SS7 MSU 800 includes layer 2 and layer 3 portions 

10 802 and 803 and opening and closing portions 804 and 805, as previously 
described. Layer 3 portion 802 includes an SIO value 806, a routing label 
807. and other layer 3 information 808. Other layer 3 information 808 can 
include ISUP information, application part information, or MTP3 information, 
as previously described. In the illustrated embodiment, all of layer 3 

15 information 803 is encapsulated in service portion 810 of TALI packet 812. 

TALI packet 812 includes LENGTH field 814. OPCODE field 816. and 
SYNC field 818. In addition, TALI packet 812 includes SSCOP trailer 820. 
LENGTH field 814 specifies the number of octets in service portion 810, 
OPCODE field 816 is set to a predetermined value for identifying TALI 

20 packet 812 as a SAAL packet, and SYNC field 818 is set to a predetermined 
value for indicating the beginning of TALI packet 812. SSCOP trailer 820 
contains a sequence number for sequencing TALI service data packets 
when a TCP/IP link fails. TALI packet 812 is encapsulated in network frame 
522 in the manner described above. SAAL decapsulation can occur in a 
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manner similar to that described above with respect to Figure 6 if service 
portion 810 of TALI packet 812 contains an SS7 MSU. If service portion 810 
of TALI packet 812 contains a SAAL peer-to-peer message, decapsulation 
may be performed by the SAAL layer, rather than the TALI layer. 

5 

TALI State Machine 
Table 1 shown below is a state machine for the TALI protocol. In 
Table, 1. columns represent protocol states and the rows represent events 
that may or may not cause transitions between protocol states. Blank cells 

10 in the table indicate that no action occurs for a given state in response to a 
given event. Cells with text indicate functions performed by TALI protocol 
implementations and state transitions that occur in response to events. 

The states in the TALI protocol are: out-of-service (OOS), 
connecting, near end prohibited - far end prohibited (NEP-FEP), near end 

15 prohibited - far end allowed (NEP-FEA), near end allowed - far end 
prohibited (NEA-FEP), and near end allowed - far end allowed (NEA-FEA). 
In the out of service state, a TCP connection has either not been established 
or has been disabled. In the connecting state, a TCP connection is being 
established between TCP software associated with TALI endpoints. 

20 "Prohibited" refers to a condition in which a TCP connection is established 
but TALI sen/ice messages are not permitted to be sent to the side for which 
message flow is prohibited. Rnally, "allowed" refers to the willingness of one 
side of a connection to accept TALI service messages. As used herein, 
TALI service messages are messages that carry application data. TALI 
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messages are messages such as allow, prohibit, monitor, and test, that carry 
TALI control information. SAAL messages that are not used to carry 
application data also fall into the TALI messages group. Thus, when in the 
prohibited state, TALI messages are permitted, while TALI service messages 
5 are not permitted. 

The events listed in column 1 of Table 1 include timer expirations, 
receipt of messages, protocol violations, etc. The TALI protocol includes 
four main timers: Tl. T2, T3, and T4. The T1 timer represents the time 
interval between the origination of a test message at each TALI 

10 implementation. Each time T1 expires, a TALI implementation should send 
a test message. The test message will be discussed in more detail below 
with regard to monitoring the status of a TALI connection. 

The timer T2 represents the amount of time that a TALI 
implementation has to retum an allow or a prohibit message in response to a 

15 test message. If the far end of a TALI connection fails to reply with an allow 
or prohibit message before T2 expires, the sender of the test message treats 
the T2 message as a protocol violation (PV). 

The timer T3 controls the length of time that the near end of the TALI 
connection should process service data that is received from the far end of a 

20 TALI connection after a management prohibit traffic event has occurred at 
the near end. As used herein, a "management event" is an action performed 
by an application that resides above and uses the TALI layer. The timer T3 
is used when a transition from NEA-FEA (both ends allowed to send service 
data) to NEP-FEA (only far end willing to send service data) occurs. When 
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an endpoint transitions to the prohibited state, the endpoint is indicating that 
the endpoirit desires to stop receiving service message traffic. That is, if A 
and B are the endpoints, and endpoint B wishes to not receive service 
message traffic, then endpoint B sends a prohibit message to endpoint A. 
5 After sending the prohibit message, endpoint B receives and processes 
traffic for T3 seconds. After T3 expires, no service messages are processed 
by endpoint B. Endpoint A starts diverting traffic to a node other than 
endpoint B once it receives the prohibit message from endpoint B. 

Some data may have been given to the TCP layer at endpoint A for 

10 transmission after endpoint B sent the prohibit message but before the 
prohibit message was received by endpoint A. The application at endpoint A 
does not have control over messages already given to TCP. If endpoint B 
did not wait some amount of time, then endpoint B would discard valid 
messages. Endpoint A would stop passing data to the TCP layer once It has 

1 S received the prohibit message. 

The T4 timer represents the time interval between the origination of 
the monitor message. Each time T4 expires, the TALI implementation 
should send a monitor message. The use of monitor messages to measure 
the round trip time of a connection will be discussed in more detail below. 

20 Other messages illustrated in the events column of Table 1 are 

special (spcl) messages and extended service (xsrv) messages. Extended 
service messages are use to transport types of sen/ice traffic other than 
those described above. Special messages are vendor specific messages 
used to provide services other than those provided by TALI. 
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Another feature of the invention illustrated in Table 1 is the use of 
monitor messages to identify the TALI software version of the far end of a 
TALI connection. For example, according to Table 1. when an 
implementation receives a monitor message in any state except out of 
5 service or connecting, the implementation updates the TALI version of the 
far end of the connection. Exemplary fields in the monitor message used to 
identify TALI version will be discussed in more detail below. 

The following description illustrates an exemplary path through the 
state machine illustrated in Table 1. First, TCP software associated with a 

10 near end TALI implementation may establish a TCP connection with TCP 
software associated with a far end TALI implerhentation. During the TCP 
connection establishment phase, both TALI implementations are in the 
connecting state. Once a TCP connection is established, both TALI 
implementations are in the NEP-FEP state, indicating that TALI service 

IS messages cannot be sent When the near end TALI implementation 
receives an allow message, the state machine switches to the NEP-FEA 
state. In the NEP-FEA state, the near end TALI implementation will send an 
allow message when a management allow traffic event occurs. As used 
herein, the phrase "management allow traffic evenf refers to an event that 

20 notifies the TALI implementation that service messages can be sent on the 
socket in question. Once the near end TALI implementation sends an allow 
message, the state machine transitions to the NEA - FEA state. In the NEA 
- FEA state, both TALI implementations can send and receive TALI service 
messages. 
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Table 1: TALI State Machine 



STATE-* 
EVENTS 


OOS 


Connecting 


NEP-FEP 


NEP-FEA 


NEA-FEP 


NEA-FEA 


T1 Timer 






Send test 
SUrtTl 
Start f2 


Send test { 
Start T1 1 
Start T2 i 


Send test 
Start T1 
Start T2 


Send test 
Start T1 
Start T2 


T2 Timer 
Expired 






PV 


PV 


PV 


PV 


T3 Timer 
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PV 


PV 






T4 Timer 
Expired 




i 


Sendmoni 
Start 14 


Sendmoni 
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Start T4 


Sendmoni 
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Test 
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Sendproh 


Send proh 


Send alio 
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Stop T2 
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Stop T2 


StopT2 
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i Received 
i Prohibit 
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StopT3 
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version* based 
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Convert moni to 
mona 
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send mona 
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version' based 
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send mona 
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Monitor 
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Implementation 

dependent 

processing. 


Implementation 

dependent 

processing. 


Implementation 

dependent 

processing. 


Implementation 

dependent 

processing. 


'» Received 
: Service 
i Message 




PV 


If T3 running i PV 

Process data | 
Else PV • 


Process data 


i Received 
[ 'ngmt' 
j Message 






If far end 
version' < 2.0 

PV 
Bse 

Process 
according to the 
nodes 2.0 mgmt 
capabilities. 
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version' < 2.0 

PV 
Else 

Process 
according to the 
nodes 2.0 mgmt 
capabilities. 


If Yarend 
version* < 2.0 

PV 
Else 

Process 
according to 
the nodes 2.0 
mgmt 

capabilities. 


If lar end 
version' < 2.0 

PV 
Else 

Process 
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the nodes 2.0 
mgmt 

capabilities. 


Received 
•xsrv' 
t Message 

i 
i 

i 
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version* < 2.0 

PV 
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according to the 
nodes 2.0 xsrv 
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1 the nodes 2.0 
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PV 
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Process 
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STATE-> 
EVENT i 
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NEP-FEA 


NEA-FEP 
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'spd' 

Message 
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PV 
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Identifying Individual Message Packets Received over Stream-Oriented 

Connection 

As discussed above, one of the problems associated with receiving 
5 data over a stream-oriented connection, such as a TCP connection, is that 
the packet boundaries created by a sending application may not be 
presen/ed by the underlying TCP software. As a result, the receiving 
application may not receive data in the intended units. The present 
embodiment solves this problem with regard to TALI packets using the 

10 SYNC and LENGTH fields. Figure 9 is a flowchart illustrating exemplary 
steps that may be performed by TALI process 322 illustrated in Figure 3 for 
identifying TALI packets received over a stream-oriented connection. In step 
ST1. a stream-oriented connection such as a TCP connection is established 
between endpoints. The endpoints may be a signaling gateway and a media 

15 gateway controller. In step ST2, TALI process 322 receives data over the 
connection. In step ST3. TALI process 322 reads a predetermined number 
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of bytes to extract the header from the stream of data received over the 
connection. The predetermined number of bytes is equal to the size of the 
header as set by the TALI version. For example, the header may be twenty 
bytes in length. 

3 In step ST4, TALI process 322 breaks the header into SYNC, 

OPCODE, and LENGTH fields. In step ST5. TALI process 322 determines 
whether the value in the SYNC field is valid. If the value in the SYNC field is 
not valid, TALI process 322 treats the message as a protocol vioiation. If 
TALI process 322 determines that the SYNC field is valid, TALI process 322 

10 may then determine whether the LENGTH and OPCODE fields are valid 
(step ST7). In step ST8, TALI process 322 reads the next LENGTH bytes in 
the data stream after the header. In step ST9, TALI process 322 passes the 
packet up the protocol stack to be processed by the TALI state machine. 
Once the TALI packet has been passed up the protocol stack, TALI process 

15 322 returns to step ST3 to read the next data header. Because tALI 
process 322 uses the SYNC and LENGTH fields to determine packet 
boundaries. SS7 application design is greatly simplified. There is ho need 
for an SS7 application to be concerned with packet boundaries. 

20 TALI Peer-To-Peer Messaces 

TALI peer-to-peer messages are messages that are transmitted by 
the TALI layer of one side of a stream-oriented connection and that are 
terminated by the TALI layer of the other side of a stream-oriented 
connection. The TALI peer-to-peer messages that are described herein 
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indude test messages for testing the status of a connection, allow and 
prohibit messages for allowing and prohibiting communications over a 
connection without invoking TCP connection establishment or termination 
procedures, and monitor messages for measuring the round trip time of a 

5 connection. Each of these messages will now be discussed in more detail. 

Test messages are used by a TALI implementation to query the 
remote end of a TALI connection with respect to the willingness of the 
remote end to carry SS7 service data. Test messages are preferably sent 
periodically by each TALI implementation based on a predetermined timeout 

10 value. Upon receiving a test message, a TALI implementation must reply 
with either a prohibit or an allow message to indicate whether the TALI 
implementation will carry SS7 sen/ice data over a TALI connection. If no 
response is received within the predetermined time period, the connection 
may be reset and/or reestablished. 

15 Table 1 below Illustrates the packet structure of a test message. In 

Table 1, the test message includes a SYNC field, an OPCODE field, and a 
LENGTH field. The SYNC field is set to TALI, the OPCODE field is set to 
test, and the LENGTH field is set to 0. 



Octets 


Field Name | Description 

1 


0..3 


SYNC 


TALI" 


4..7 


OPCODE 


'test* 


8..9 


LENGTH 


Length = 0 



20 Table 1 : Test Message 
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Rgure 10 is a flowchart illustrating exemplary steps that may be 
performed by a TALI process in monitoring the status of the connection 
using test messages. In step STI, TALI process 322 sends a test message 
5 to a peer on the other side of a connection. In step ST2, TALI process 322 
starts timers T1 and T2. The timer T1 may be used to determine when to 
send the next test message and the timer T2 may be used to determine the 
time for receiving a valid response to the test message. In step ST3. timers 
T1 and T2 are compared to predetermined values. For example, the 

10 predetermined value for timer T1 may be set to a time period for sending the 
next test message. The timer value T2 may be set to a predetermined time 
period that is preferably less than the keep-alive timer for TCP. For 
example, the timeout period may be set for two round trip times for the given 
connection. A method for measuring the round trip time of a connection will 

15 be discussed in more detail below. 

In step ST4, TALI process 322 determines whether the timer T2 has 
expired or stopped. The timer T2 expires when it reaches the timeout period 
set for T2. The timer T2 stops when an allow or a prohibit message is 
received. If the timer T2 has not expired or stopped, TALI process 322 

20 continues to check the timer. In step ST5. if TALI process 322 determines 
that the timer T2 has expired. TALI process 322 detemriines whether a valid 
response to the test message has been received. As discussed above, a 
valid response to the test message may be an allow message or a prohibit 
message. If a valid response has been received, TALI process 322 
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determines whether timer T1 has expired or stopped, and. if so. sends 
another test message to the other side (steps ST6 and ST1). In step ST7. if 
a valid response has not been received, TALI process 322 may reset and 
attempt to reestablish the connection. Since the timeout period is preferably 
5 less than that of a TCP connection, monitoring of connection status using 
test messages provides more efficient connection management that TCP. 
Moreover, because test messages are periodically sent and acted upon, 
TALI connections can be reliably maintained. 

10 Allow and Prohibit Messages 

As discussed above, the TALI protocol provides allow and prohibit 
message for allowing and prohibiting communications over a TCP 
connection without invoking TCP connection and establishment and 
termination procedures. The allow message is sent in reply to a test query 

15 or in response to an internal implementation event to indicate that a TALI 
implementation is willing to carry SS7 service data over a TALI session. As 
used herein, a TALI session refers to TALI-level connection between 
endpoints. A TALI session may be created by establishing a TCP 
connection followed by the exchange of allow messages, as will be 

20 discussed in more detail below. The allow message informs the far end that 
SS7 traffic can be transmitted on the connection. Allow is one of two 
possible valid replies to a test message. Before SS7 traffic can be carried 
over a connection, both ends of the connection are required to send allow 
messages to each other. Table 2 shown below illustrates an exemplary 
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packet structure for an allow message. In Table 2, the allow message 
includes a SYNC field, an OPCODE field, and a LENGTH field. The SYNC 
field is set to TALI to indicate that the packet is a TALI packet The 
OPCODE field is set to 'alio' to identify an allow message. The LENGTH 
3 field is set to 0. since the sen^ice portion of the TALI packet does not carry 
any data. 



Octets 


Field Name 


Description 


0..3 i SYNC 


TALI' 


4..7 


OPCODE 


'alio' 


8..9 


LENGTH 


Length = 0 



Table 2: Allow Message 



Like the allow message, the prohibit message is sent in reply to a test 
10 query or in response to an intemal implementation event. However, unlike 
the allow message, the purpose of the prohibit message is to indicate that a 
TALI implementation is not willing to carry SS7 service over the TALI 
session. The prohibit message infomis the far end that SS7 traffic cannot be 
transmitted over the connection. As long as one end of the connection 
IS remains prohibited, SS7 traffic cannot be carried over the connection. Table 
3 illustrates an exemplary packet structure for a prohibit message. In Table 
3. the prohibit message includes a SYNC field, an OPCODE field, and a 
LENGTH field. The SYNC field is set to TALI to identify the message as a 
TALI packet. The OPCODE field Is set to 'proh' for prohibit. The LENGTH 
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field is set to 0, since the message does not carry any data in the service 
portion of the message. 



Octets 


Field Name 


Description 


0..3 


SYNC 


TALI' 


4..7 


OPCODE 


•prah* 


8..9 


LENGTH 


Length = 0 



Table 3: Prohibit Message 



5 A prohibit acknowledgement message is a message sent by TALI 

implementation in response to receiving a prohibit message from the far end 
of a connection. Receipt of a prohibit acknowledgement message indicate 
that the prohibit message was received correctly and will be acted on 
accordingly. The side of a connection receiving a prohibit acknowledgement 

10 message can thus assume that no more data will be transferred over the 
connection and that it is okay to perform some desired action associated 
with the connection. Table 4 shown below illustrates a prohibit 
acknowledgement message according to an embodiment of the present 
invention. In Table 4, prohibit acknowledgement message includes a SYNC 

15 field, an OPCODE field, and a LENGTH field. The SYNC field may include 
the value TALI to indicate that the message is a TALI message. The 
OPCODE field may store the value 'proa' to indicate that the message is a 
prohibit acknowledgement message. The LENGTH field may include a 
value of 0. because the service portion of the message does not contain any 

20 data. 
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Octets 


Field Name 


Description 


0..3 


SYNC 


TALI* 


4.7 


OPCODE 


'proa' 


8..9 


LENGTH 


Length = 0 



Table 4: Prohibit Acknowledgement Message 



Figure 1 1 is a flowchart illustrating the advantages of using prohibit 
5 and acknowledgement messages to enable and disable connections. In 
step ST1, a TALI session is established between two nodes, node A and 
node B. Nodes A and B may each be any type of node previously described 
in which it is desirable to implement a TALI protocol stack. For example, 
either node may be a signaling gateway, a media gateway controller, or an 
10 IP-capable SCP. Establishing a TALI session may include establishing a 
TCP connection between nodes A and B followed by the exchange of allow 
messages between nodes A and B. Once the connection is established and 
communications are allowed, in step ST2. nodes A and B communicate 
using the TALI session. Such communication may include exchange of SS7 
15 call signaling messages, such as SCCP messages, TCAP messages. ISUP 
messages, and MTP3 messages. In step ST3, node A sends a prohibit 
message to node B. The reason for sending the prohibit message may be 
that node A desires to perform a software upgrade. In step ST4, node A 
determines whether a prohibit acknowledge message has been received. If 
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a prohibit acknowledge message has not been received, node A may 
retransmit the prohibit message. 

In step ST5, once node A receives the prohibit acknowledge 
message, node A can assume that data will not be received from node B 

5 over the prohibited connection. Accordingly, the manager of node B can 
perform some desired action, such as a software upgrade. When the 
desired action is complete, in step ST6. node A can send an allow message 
to node B over the connection. Once node B receives the allow message, 
node B can resume communications over the disabled connection. Because 

10 a transport adapter layer internee connection can be allowed and prohibited 
without invoking TCP connection establishment and termination procedures, 
the time and processing resources required for these operations are reduced 
over conventional TCP procedures. 



15 Performance Measurement and Version Identification 

According to another aspect of the invention, messages may be sent 
between TALI implementation to measure performance of a specific 
connection and to communicate the TALI version number between 
communication endpoints. One performance measurement that may be of 

20 interest is the round trip time. The round trip time is the time for a message 
to travel from one side of a connection to the other and back. The vehicle for 
measuring the round trip time according to the present embodiment includes 
a monitor message and a monitor acknowledgement message. A monitor 
message provides a generic echo capability that can be used by a TALI 
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implementation in order to measure the round trip time. Table 5 shown 
beiow is an example packet structure for the monitor message. In Table 5. 
the monitor message includes a SYNC field, an OPCODE field, a LENGTH 
field. . a version label field, and a Data field. The SYNC field identifies the 
5 monitor message as a TALI message. The OPCODE field includes the 
value 'moni' to identify the message as a monitor message. The LENGTH 
field includes the length of the data portion of the monitor message, which 
contains vendor-dependent data. The version label field in the monitor 
message may be used to communicate the TALI version number to the far 
10 end of a connection. The possible version label field values xxx.yyy specify 
the major and minor TALI version numbers. For example, a version label 
field value of 001 .000 specifies TALI version 1 .0. 



Octets 


Field Name 


Description 


Type of Field 


0..3 


SYNC 


TALI' 


4 byte Ascii text ! 


4..7 


OPCODE 


'moni' 


4 byte Ascii text 


: 8,.9 


LENGTH 


Length (include the 
version label and data 
fields) 


Integer 


10.. 21 


VER. LABEL 


Vers xxx.yy/ 


12 byte Ascii text 


22..X 


Data 


Vendor Dependent 
Maximum length of this 
message (as coded in 
bytes 8-9, and stored in 
bytes 10-x) should not 
exceed 200 bytes 


Variable 



Table 5: Version Control 'moni' Message 
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In response to receiving a monitor message, a TALI session 
preferably sends a monitor acknowledgement message. Table 6 shown 
below illustrates an example packet structure for a monitor 
acknowledgement message. In the Illustrated example, the monitor 

S acknowledgement message includes a SYNC field, an OPCODE field, a 
LENGTH field, and a Data field. The SYNC field stores the value TALI to 
indicate the start of a TALI packet. The OPCODE field stores the value 
'mona' to identify the packet as a monitor acknowledgement message. The 
LENGTH field stores the length of the data portion of the monitor 

10 acknowledgement message. The data portion of the monitor 
acknowledgement message preferably includes the same data that was sent 
in the monitor message. The matching of data allows the monitor message 
to be paired with the monitor acknowledgement message. 



'■ Octets 


Field Name 


Description 


0..3 


SYNC 


'TALI' 


4.7 


OPCODE 


'mona' 


8..g 


LENGTH 


Length 


; 10..X 


Data 


Vendor 
Dependent 



1 S Table 6: Monitor Acknowledgement Message 

Figure 12 is a flowchart Illustrating the use of the monitor message 
and the monitor acknowledgement message to measure the round trip time 
of a connection and to communicate the TALI version number to the far end 
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of a connection. In step STl a TALI implementation reads a timer value 
associated with the local machine and includes the timer value in a monitor 
message. In step ST2. the TALI implementation places its TALI version 
number in the monitor message. The version number is used by the other 
5 side of a TALI connection to keep track of the version number. For example, 
upon receiving a monitor message, an endpoint may determine whether the 
monitor message has a valid version label value in the version label field. 
This may include comparing bytes located where the version label field 
should be in the monitor message to a predetermined list of version values. 

10 If the value matches one of the values in the list, then the endpoint stores 
that value as the TALI version for the other side. If the match is not found, 
the endpoint may store a default version for the other side. e.g.. 1 .0, Since 
both sides, of a connection preferably send monitor messages to each other 
and the monitor messages can include the sending sides TALI version 

15 number, each side of the connection can determine the current version of 
the other side. 

In step ST3, the TALI implementation sends the monitor message to 
the other side of a connection. As discussed above, the other side of the 
connection may use the version label to update the TALI version of the 
20 sending side. The other side of the connection changes the OPCODE of the 
message from monitor to monitor acknowledgment and sends the message 
back to the sending TALI implementation. In step ST4, the TALI 
implementation receives the monitor acknowledgement message from the 
other side of the connection and extracts a timer value from the monitor 
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acknowledgement message. In step ST5, the TALI implementation reads 
the local timer value when the monitor acknowledgement message was 
receivejd. In step ST6, the TALI implementation computes the round trip 
time for the connection based on the difference between the local timer 
5 value when the monitor message was received and timer value read from 
the monitor acknowledgement message. Computing the round trip time in 
this manner allows optimization of other timers, such as retransmission 
timers. 



10 Authentication of Critical Messaoes 

As indicated above, many of the messages sent between TALI 
implementations can allow and/or prohibit communications over a 
connection. Since such messages could be disastrous in a 
telecommunications environment, it is preferable that security messages be 

15 implemented to ensure that only authorized users can send these 
messages. One method for providing this security is to authenticate critical 
messages. Examples of critical messages described herein are prohibit 
messages and test messages. To ensure that these messages are 
transmitted by authorized users, encryption and/or authentication procedures 

20 can be used. In one example, a public key encryption algorithm, such as 
Rivest, Shamir. Adteman (RSA), can be used to verify that the message 
originated from an authorized user. In order to authenticate a message 
using a public key encryption algorithm, the sending node sends its public 
key to the receiving node. The sending node then signs the message using 
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ils private key. The receiving node then authenticates the message using 
the sending node's public key. If the message authenticates correctly, i.e., if 
a valid TALI message is received, then the receiving node knows that the 

I 

message came from an authorized user. In this manner, the security of TALI 
5 connections can be increased. 

According to another aspect of the invention, critical messages may 
be authenticated in a different manner using a public key cryptosystem. For 
example, a sender and a receiver may exchange public keys. That Is, the 
sender S may send S's public key to the receiver R, and R may send R*s 

10 public key to S. S may then encrypt a critical message, such as a prohibit 
message using R*s public key. When R receives the message. R may 
decrypt the message using R's private key. If the message decrypts 
correctly, R knows that the message comes from someone who has access 
to R's public key. R may then encrypt a response message, such as a 

15 prohibit acknowledgement message, using S*s public key. R may then send 
the message to S. S may decrypt the message using S's private key. If the 
message decrypts correctly, S knows that the message originated from 
someone with access to S's public key. In this manner, two-way 
authentication may be achieved. 

20 It will be understood that various details of the invention may be 

changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation — the invention being defined by the claims. 



SUBSTITUTE SHEET (RULE 26) 



wo 00n6134 



PCTA;S00/15561 



CLAIMS 

What Is claimed is: 

1. A method for encapsulating a signaling connection control part (SCCP) 
message in an Internet protocol (IP) datagram using a transport 
5 adapter layer interface (TALI), the method comprising: 

(a) receiving an SS7 message signal unit (MSU). the SS7 MSU 
including message transfer part (MTP) layers 1, 2, and 3 and an 
SCCP layen 

(b) discarding MTP layer 1 and 2 information from the SS7 MSU; 
1 0 (c) placing the SCCP layer in a service portion of a TALI packet; 

(d) adding a TALI header to the TALI packet; and 

(e) adding transmission control protocol (TCP) and IP headers to the 
TALI packet. 



IS 2. The method of claim 1 comprising placing MTP layer 3 information 
without modification into the service portion of the TALI packet 



3. The method of claim 1 comprising extracting MTP layer 3 information 
from the SS7 MSU and placing the MTP layer 3 information in the 
20 SCCP layer. 



4. The method of claim 3 wherein extracting MTP layer 3 information 
includes extracting an originating point code (OPC) value from the SS7 
MSU and placing the MTP layer 3 information in the SCCP layer 
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indudes placing the OPC value in a calling party address field in the 
SCCP layer. 

5. The method of claim 3 wherein extracting MTP layer 3 information 
S includes extracting a destination point code (DPC) value from the SS7 

MSU and placing the MTP layer 3 information in the SCCP layer 
includes placing the DPC value in a called party address field in the 
SCCP layer. 

10 6. The method of claim 1 comprising setting a SYNC field in the TALI 
packet to a predetermined value indicating the beginning of the TALI 
packet for stream-oriented communications. 

7. The method of claim 1 comprising setting a LENGTH field in the TALI 
IS packet to a value indicative of the LENGTH of the service portion of the 

TALI packet. 

8. The method of claim 1 comprising setting an OPCODE field in the TALI 
packet to a predetermined value for identifying the TALI packet as an 

20 SCCP packet. 

9. A method for encapsulating a message transfer part layer 3 (MTP3) 
packet in an Internet protocol (IP) datagram using a transport adapter 
layer interface (TALI), the method comprising: 
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(a) receiving an MTP3 message signal unit (MSU). the MTP3 MSU 
including MTP layers 1 . 2. and 3; 

(b) discarding MTP layers 1 and 2 from the MTP3 MSU; 

(c) placing MTP layer 3 information from the MTP3 MSU in a service 
S portion of a TALI packet; 

(d) adding a TALI header to the TALI packet; and 

(e) adding transmission control protocol (TCP) and IP headers to the 
TALI packet. 

10 10. The method of claim 9 wherein placing the MTP layer 3 information in 
the service portion includes placing a routing label and a service 
indicator octet (SIO) in the service portion of the TALI packet. 

11. The method of claim 10 wherein placing the MTP layer 3 information in 
IS the service portion includes placing layer 3 information in addition to 

the routing label and the SIO in the service portion of the TALI packet. 

12. The method of claim 11 wherein placing information in addition to the 
routing label and the SIO includes placing network management 

20 information in the service portion of the TALI packeL 

13. The method of claim 12 wherein placing network management 
information in the service portion of the TALI packet Includes placing 
changeover information in the service portion of the TALI packet. 
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14. The method of claim 12 wherein placing network management 
information in the sen^ice portion of the TALI packet includes placing 
changeback Information in the service portion of the TALI packet. 

5 15. The method of claim 12 wherein placing network management 
information in the service portion of the TALI packet includes placing 
flow control information in the service portion of the TALI packet 

16. The method of claim 11 wherein placing information in addition to the 
10 routing label and the SIO includes placing network testing information 

in the service portion of the TALI packet. 

17. The method of claim 16 wherein placing network testing information in 
the service portion of a TAl.1 packet includes placing signaiing-route- 

15 set-test information in the service portion of the TALI packet 

18. The method of claim 9 comprising setting a SYNC field in the TALI 
packet to a predetermined value indicating the beginning of the TALI 
packet for stream-oriented communications. 



20 



19. The method of claim 9 comprising setting a LENGTH field in the TALI 
packet to a value indicative of the LENGTH of the service portion of the 
TALI packet. 
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20. The method of claim 9 comprising setting the OPCODE field to a 
predetemnined value for identifying the TALI packet as an MTP3 
packet. 

5 21. The method of claim 9 comprising adding an application layer 
sequence number to the TALI packet. 

22. The method of claim 21 comprising adding an application layer 
sequence number includes adding a service specific connection 
10 oriented protocol (SSCOP) trailer to the TALI packet. 



23. A method for monitoring the status of a transmission control protocol 
(TCP) connection used to communicate SS7 messages between SS7 
and Internet protocol (IP) nodes, the method comprising: 
IS (a) establishing a first transmission control protocol (TCP) connection 

for communicating SS7 messages between a first signaling node 
and a second signaling node; 
(b) transmitting a first message encapsulated in a TCP segment over 
the first TCP connection; 
20 (c) listening for a reply to the first message over the first TCP 

connection; and 

(d) in response to failing to receive the reply within a predetermined 
time period, treating the first TCP connection as being disabled. 
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24. The method of claim 23 comprising in response to failing to receive the 
reply within the predetermined time period, attempting the re-establish 
communications over the first TCP connection. 

5 25. The method of claim 23 wherein the predetermined time period is less 
than a TCP disconnection timeout value. 

26. The method of claim 23 wherein transmitting a first message includes 
transmitting a TALI test message and listening for a reply includes 

10 listening for a TALI allow or prohibit message. 

27. The method of claim 23 comprising, in response to receiving the reply, 
determining a round trip time (RTT) between the first and second 
signaling nodes. 

15 

28. The method of claim 27 wherein determining a round trip time includes: 

(a) ' reading a local timer value and inserting the local timer value in 

the first message; 

(b) reading the local timer value when the reply is received; 
20 (c) reading a timer value from the reply; and 

(d) computing the RTT based on the difference between the timer 
value in the reply and the local timer value when the reply was 
received. 
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29. The method of claim 23 comprising inserting a local transport adapter 
layer interface version number in the first message. 

30. A method for suspending and resuming SS7 message communications 
5 over a transmission control protocol (TCP) connection, the method 

comprising: 

(a) establishing a first TCP connection between a first signaling node 
and a second signaling node; 

(b) sending and receiving TCP/IP-encapsulated SS7 messages over 
1 0 the first TCP connection; and 

(c) receiving a first control message over the first TCP connection 
and, in response, stopping the sending of SS7 messages over the 
first TCP connection. 



15 31. The method of claim 30 comprising, after receiving the first control 
message, resuming the sending of SS7 messages over the first TCP 
connection in response to receiving a second control message over the 
first TCP connection. 

20 32. The method of claim 30 comprising, in response to receiving the first 
control message, sv^^itching SS7 communications between the first and 
second signaling nodes to a second TCP connection established 
between the first and second signaling nodes. 
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33. The method of claim 30 wherein receiving a first control message 
includes receiving the first control message signed using a 
predetermined encryption algorithm and verifying that the first control 
message originating from an authorized node using the first encryption 

5 algorithm. 

34. The method of claim 30 wherein establishing a TCP connection 
between first and second signaling nodes includes establishing the first 
TCP connection between a signaling gateway and a media gateway 

10 controller. 

35. The method of claim 30 wherein establishing a connection between 
first and second signaling nodes includes establishing a connection 
between a first SS7 signaling node and an IP node. 

15 

36. ~ The method of claim 30 wherein establishing a connection between 

first and second signaling nodes includes establishing a connection 
between a first IP-capable SS7 signaling node and a second IP- 
capable SS7 node. 

20 

37. A method for processing transport adapter layer interface (TALI) 
messages received over a stream-oriented connection, the method 
comprising: 
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(a) receiving a plurality of TALI messages over a stream-oriented 
connection; 

(b) identifying the beginning of each of the TALI messages using a 
first field In each of the TALI messages; 

5 (c) identifying the end of each of the TALI messages using a second 

field in each of the TALI messages; and 
(d) extracting individual TALI message packets using the first and 
second fields. 

10 38. The method of claim 37 comprising identifying the content of each of 
the TALI messages using a third field in each of the TALI messages. 

39. The method of claim 37 wherein receiving a plurality of TALI messages 
over a stream-oriented connection includes receiving a plurality of TALI 
1 S messages over a transmission control protocol (TCP) connection. 



40. The method of claim 37 wherein identifying the beginning of each of the 
TALI messages includes identifying each of the TALI messages using a 
SYNC field in each of the TALI messages. 

20 

41 . The method of claim 37 wherein identifying the end of each of the TALI 
messages using a second data field includes identifying the end of 
each of the TALI messages using a LENGTH field for specifying the 
length of a data portion of each of the TALI messages. 
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42. The method of claim 38 wherein identifying the content of each of the 
TALI messages using a third data field includes identifying the content 
of each of the TALI messages using an OPCODE field for specifying 
the content of each of the TALI messages. 

5 

43. The method of claim 37 wherein a data portion of each of the TALI 
messages carries SS7 information. 

44. A computer program product comprising computer-executable 
10 instructions embodied In a computer-readable medium for performing 

steps comprising: 

(a) receiving an SS7 message signal unit (MSU). the SS7 MSU 
including message transfer part (MTP) layers 1, 2, and 3 and an 
SCCP layer. 

15 (b) discarding MTP layer 1 and 2 information from the SS7 MSU; 

(c) placing the SCCP layer in a service portion of a TALI packet: 

(d) adding a TALI header to the TALI packet; and 

(e) adding transmission control protocol (TCP) and IP headers to the 
TALI packet. 

20 

45. The computer program product of claim 44 comprising placing MTP 
layer 3 information without modification into the service portion of the 
TALI packet. 
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46. The computer program product of claim 44 comprising extracting MTP 
layer 3 information from the SS7 MSU and placing the MTP layer 3 
information in the SCCP layer. 

47. The computer program product of claim 46 wherein extracting MTP 
3 layer 3 infomiation includes extracting an originating point code (OPC) 

value from the SS7 MSU and placing the MTP layer 3 information in 
the SCCP layer includes placing the OPC value in a calling party 
address field in the SCCP layer. 



10 48. The computer program product of claim 46 wherein extracting MTP 
layer 3 information includes extracting a destination point code (DPC) 
value from the SS7 MSU and placing the MTP layer 3 information in 
the SCCP layer includes placing the DPC value in a called party field 
address in the SCCP layer. 

15 

49. The computer program product of claim 44 comprising setting a SYNC 
field in the TALI packet to a predetermined value indicating the 
beginning of the TALI packet for stream-oriented communications. 

20 50. The computer program product of claim 44 comprising setting a 
LENGTH field in the TALI packet to a value indicative of the LENGTH 
of the service portion of the TALI packet. 
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51. The computer program product of claim 44 comprising setting an 
OPCODE field in the TALI packet to a predetemnined value for 
identifying the TALI packet as an SCCP packet. 

5 52. A computer program product for comprising computer*executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) receiving an MTP3 message signal unit (MSU), the SS7 MSU 
including MTP layers 1 . 2, and 3; 
10 (b) discarding MTP layers 1 and 2 from the MTP3 MSU; 

(c) placing MTP layer 3 information from the MTP3 MSU in a service 
portion of a TALI packet; 

(d) adding a TALI header to the TALI packet; and 

(e) adding transmission control protocol (TCP) and IP headers to the 
!5 TALI packet. 



53. The computer program product of claim 52 wherein placing the MTP 
layer 3 information in the service portion includes placing a routing 
label and a service indicator octet (SIO) in the service portion of the 

20 TALI packet. 

54. The computer program product of claim 53 wherein placing the MTP 
layer 3 information in the service portion includes placing layer 3 
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information in addition to the routing label and the SIO in the service 
portion of the TALI packet. 

55. The computer program product of claim 53 wherein placing information 
5 in addition to the routing label and the SIO, includes placing network 

management information in the service portion of the TALI packet. 

56. The computer program product of claim 55 wherein placing network 
management information in the service portion of the TALI packet 
includes pladng changeover information in the service portion of the 

10 TALI packet 

57. The computer program product of claim 55 wherein placing network 
management information in the service portion of the TALI packet 
includes placing changeback infonmation in the service portion of the 

15 TALI packet 



58. The computer program product of claim 55 wherein placing network 
management information in the service portion of the TALI packet 
includes placing flow control information in the service portion of the 

20 TALI packet 

59. The computer program product of claim 54 wherein placing information 
in addition to the routing label and the SIO includes placing network 
testing infonmation in the service portion of the TALI packet. 
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60. The computer program product of claim 59 wherein placing network 
testing information in the sen/ice portion of a TALI packet includes 
placing signaling-route-set-test information in the service portion of the 
TALI packet. 

5 

61. The computer program product of claim 52 comprising setting a SYNC 
field in the TALI packet to a predetermined value indicating the 
beginning of the TALI packet for stream-oriented communications. 

10 62. The computer program product of claim 52 comprising setting a 
LENGTH field in the TALI packet to a value indicative of the LENGTH 
of the service portion of the TALI packet. 

63. The computer program product of claim 52 comprising setting the 
15 OPCODE field to a predetemiined value for identifying the TALI packet 

as an MTP3 packet. 

64. The computer program product of claim 52 comprising adding an 
application layer sequence number to the TALI packet. 

20 

65. The computer program product of clairh 64 comprising adding an 
application layer sequence number includes adding a service specific 
connection oriented protocol (SSCOP) trailer to the TALI packet. 
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66. A computer program product comprising computer-executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) establishing a first transmission control protocol (TCP) connection 
3 for communicating SS7 messages between a first signaling node 

and a second signaling node; 

(b) transmitting a first message encapsulated in a TCP segment over 
the first TCP connection; 

(c) listening for a reply to the first message over the first TCP 
10 connection; and 

(d) in response to failing to receive the reply within a predetermined 
time period, treating the first TCP connection as being disabled. 

67. The computer program product of claim 66 comprising in response to 
15 failing to receive the reply within the predetermined time period, 

attempting the re-establish communications over the first TCP 
connection. 

68. The computer program product of claim 66 wherein the predetemiined 
20 time period is less than a TCP disconnection timeout value. 

69. The computer program product of claim 66 wherein transmitting a first 
message includes transmitting a TALI test message and listening for a 
reply includes listening for a TALI allow or prohibit message. 
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70. The computer program product of claim 66 comprising, in response to 
receiving the reply, determining a round trip time (RTT) between the 
first and second signaling nodes. 

5 71. The computer program product of claim 70 wherein determining a 
round trip time includes: 

(a) reading a local timer value and inserting the local timer value in 
the first message; 

(b) reading the local timer value when the reply is received; 
10 (c) reading a timer value from the reply; and 

(d) computing the RTT based on the difference between the timer 
value in the reply and the local timer value when the reply was 
received. 

15 72. The computer program product of claim 71 inserting a local transport 
adapter layer interface version number in the first message. 

73. A computer program product comprising computer-executable 
instructions embodied in a computer-readable medium for performing 
20 steps comprising: 

(a) establishing a first TCP connection between a first signaling node 
and a second signaling node; 

(b) sending and receiving TCP/IP-encapsulated SS7 messages over 
the first TCP connection; and 
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(c) receiving a first control message over the first TCP connection 
and, in response, stopping the sending of SS7 messages over the 
first TCP connection. 

5 74. The computer program product of claim 73 comprising, after receiving 
the first control message, resuming the sending of SS7 messages over 
the first TCP connection in response to receiving a second control 
message over the first TCP connection. 

10 75. The computer program product of claim 73 comprising, in response to 
receiving the first control message, switching SS7 communications 
between the first and second signaling nodes to a second TCP 
connection established between the first and second signaling nodes. 

15 76. The computer program product of claim 73 wherein receiving a first 
control message includes receiving the first control message signed 
using a predetermined encryption algorithm and verifying that the first 
control message originated from an authorized node using the first 
encryption algorithm. 

20 

77. The computer program product of claim 73 wherein establishing a TCP 
connection between first and second signaling nodes includes 
establishing the first TCP connection between a signaling gateway and 
a media gateway controller. 
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78. The computer program product of claim 73 wherein establishing a 
connection between first and second signaling nodes includes 
establishing a connection between a first SS7 signaling node and an IP 
node. 

5 

79. The computer program product of claim 73 wherein establishing a 
connection between first and second signaling nodes includes 
establishing a connection between a first IP-capable SS7 signaling 
node and a second IP-capable SS7 node. 

10 

80. A computer program comprising computer-executable instructions 
embodied in a computer-readable medium for performing steps 
comprising: 

(a) receiving a plurality of TALI messages over a stream-oriented 
IS connection; 

(b) identifying the beginning of each of the TALI messages using a 
first field in each of the TALI messages; 

(c) identifying the end of each of the TALI messages using a second 
field in each of the TALI messages; and 

20 (d) extracting individual TALI message packets using the first and 

second fields. 
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81 . The computer program product of claim 80 comprising identifying the 
content of each of the TALI messages using a third field in each of the 
TALI messages. 

5 82. The computer program product of claim 80 wherein receiving a plurality 
of TALI messages over a stream-oriented connection includes 
receiving a plurality of TALI messages over a transmission control 
protocol (TCP) connection. 

83. The computer program product of claim 80 wherein identifying the 
10 beginning of each of the TALI messages includes identifying each of 

the TALI messages using a SYNC field in each of the SS7 messages. 

84. The computer program product of claim 80 wherein identifying the end 
of each of the TALI messages using a second data field includes 

15 identifying the end of each of the TALI messages using a LENGTH field 

for specifying the length of a data portion of each of the TALI 
messages. 

85. The computer program product of claim 81 wherein identifying the 
20 content of each of the TALI messages using a third data field includes 

identifying the content of each of the TALI messages ' using an 
OPCODE field for specifying the content of each of the TALI 
messages. 
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86. The computer program product of claim 80 wherein a data portion of 
each of the TALI messages carries SS7 information. 

87. A communications networic element for implementing a transport 
adapter layer interface (TALI) protocol stack, the communications 

5 network element comprising; 

(a) a TALI process for receiving SS7 messages, discarding SS7 layer 
1 and 2 information firom the SS7 messages, and for adding a 
TALI header to each of the SS7 messages to form TALI 
messages; and 

10 (b) a transmission control protocol/Internet protocol (TCP/IP) process 

for receiving the TALI messages from the TALI process, adding 
TCP and IP headers to the TALI messages, and forwarding the 
TALI messages to a receiving application over an IP network 
based on the TCP and IP headers. 



15 



20 



88. The communications network element of claim 87 comprising a data 
• communications module (DCf^) including hardware for sending and 

receiving messages over the IP network, wherein the TALI process is 
implemented on the DCM. 

89. The communications network element of claim 88 wherein the TCP/IP 
process is implemented on the DCM. 
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90. The communications network element of claim 87 wherein the TCP/IP 
process is adapted to receive a stream of TCP data from the iP 
network. 

5 91. The communications network element of claim 90 wherein the TALI 
process is adapted to receive the stream of TCP data from the TCP/IP 
process and to identify individual TALI message boundaries in the 
stream. 
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